home *** CD-ROM | disk | FTP | other *** search
/ Honeybee: Hot Shareware / Honeybee Hot Shareware (Power Source, Inc.).iso / viewer / gif.txt < prev    next >
Text File  |  1992-08-06  |  27KB  |  570 lines

  1.                                G I F (tm)
  2.                     Graphics Interchange Format (tm)
  3.  
  4.           A standard defining a mechanism for the storage and
  5.            transmission of raster-based graphics information
  6.  
  7.             June 15, 1987 (c) CompuServe Incorporated, 1987
  8.                           All rights reserved
  9.  
  10.           While this document is copyrighted, the information
  11.          contained within is made available for use in computer
  12.          software without royalties, or licensing restrictions.
  13.         GIF and 'Graphics Interchange Format' are trademarks of
  14.                        CompuServe, Incorporated.
  15.                           an H&R Block Company
  16.                       5000 Arlington Centre Blvd.
  17.                           Columbus, Ohio 43220
  18.                              (614) 457-8600
  19.  
  20.                               INTRODUCTION
  21.  
  22.      'GIF' (tm) is CompuServe's standard for defining generalized
  23. color raster images.  This 'Graphics Interchange Format' (tm) allows
  24. high-quality, high-resolution graphics to be displayed on a variety of
  25. graphics hardware and is intended as an exchange and display mechanism
  26. for graphics images.  The image format described in this document is
  27. designed to support current and future image technology and will in
  28. addition serve as a basis for future CompuServe graphics products.
  29.      The main focus of this  document is to provide the technical
  30. information necessary for a programmer to implement GIF encoders and
  31. decoders.  As such, some assumptions are made as to terminology
  32. relavent to graphics and programming in general.
  33.      The first section of this document describes the GIF  data  format
  34. and its components and applies to all GIF decoders, either as
  35. standalone programs or as part of a communications  package.   Appendix
  36. B is a section relavent to decoders that are part of a communications
  37. software package and describes the protocol requirements for entering
  38. and exiting GIF mode, and responding to host interrogations.  A
  39. glossary in Appendix A defines some of the terminology used in this
  40. document.  Appendix C gives a detailed explanation of how the graphics
  41. image itself is packaged as a series of data bytes.
  42.  
  43. Graphics Interchange Format Data Definition
  44.  
  45. GENERAL FILE FORMAT
  46.  
  47. +-----------------------+
  48. | +-------------------+ |
  49. | |   GIF Signature   | |
  50. | +-------------------+ |
  51. | +-------------------+ |
  52. | | Screen Descriptor | |
  53. | +-------------------+ |
  54. | +-------------------+ |
  55. | | Global Color Map  | |
  56. | +-------------------+ |
  57. . . .               . . .
  58. | +-------------------+ |    ---+
  59. | |  Image Descriptor | |       |
  60. | +-------------------+ |       |
  61. | +-------------------+ |       |
  62. | |  Local Color Map  | |       |-Repeated 1 to n times
  63. | +-------------------+ |       |
  64. | +-------------------+ |       |
  65. | |    Raster Data    | |       |
  66. | +-------------------+ |    ---+
  67. . . .               . . .
  68. |-    GIF Terminator   -|
  69. +-----------------------+
  70.  
  71. GIF SIGNATURE
  72.  
  73.      The following GIF Signature identifies the data following as a
  74. valid GIF image stream.  It consists of the following six characters:
  75.  
  76.    G I F 8 7 a
  77.  
  78.      The last three characters '87a' may be viewed as a version number
  79. for this particular GIF definition and will be used in general as a
  80. reference in documents regarding GIF that address any version
  81. dependencies.
  82.  
  83. SCREEN DESCRIPTOR
  84.  
  85.      The Screen Descriptor describes the overall parameters for all GIF
  86. images following.  It defines the overall dimensions of the image space
  87. or logical screen required, the existance of color mapping information,
  88. background screen color, and color depth information.  This information
  89. is stored in a series of 8-bit bytes as described below.
  90.  
  91. bits 7 6 5 4 3 2 1 0 Byte #
  92. +---------------+
  93. |               |  1
  94. +-Screen Width -+      Raster width in pixels (LSB first)
  95. |               |  2
  96. +---------------+
  97. |               |  3
  98. +-Screen Height-+      Raster height in pixels (LSB first)
  99. |               |  4
  100. +-+-----+-+-----+      M = 1, Global color map follows Descriptor
  101. |M|  cr |0|pixel|  5   cr+1 = # bits of color resolution
  102. +-+-----+-+-----+      pixel+1 = # bits/pixel in image
  103. |  background   |  6   background=Color index of screen background
  104. +---------------+        (color is defined from the Global color
  105. |0 0 0 0 0 0 0 0|  7     map or default map if none specified)
  106. +---------------+
  107.  
  108.      The logical screen width and height can both be larger than the
  109. physical display.  How images larger than the physical display are
  110. handled is implementation dependent and can take advantage of hardware
  111. characteristics (e.g. Macintosh scrolling windows).  Otherwise images
  112. can be clipped to the edges of the display.  The value of 'pixel' also
  113. defines the maximum number of colors within an image.  The range of
  114. values for 'pixel' is 0 to 7 which represents 1 to 8 bits.  This
  115. translates to a range of 2 (B & W) to 256 colors.  Bit 3 of word 5 is
  116. reserved for future definition and must be zero.
  117.  
  118. GLOBAL COLOR MAP
  119.  
  120.      The Global Color Map is optional but recommended for images where
  121. accurate color rendition is desired.  The existence of this color map
  122. is indicated in the 'M' field of byte 5 of the Screen Descriptor.  A
  123. color map can also be associated with each image in a GIF file as
  124. described later.  However this global map will normally be used because
  125. of hardware restrictions in equipment available today.  In the
  126. individual Image Descriptors the 'M' flag will normally be zero.  If
  127. the Global Color Map is present, it's definition immediately follows
  128. the Screen Descriptor.   The number of color map entries following a
  129. Screen Descriptor is equal to 2**(# bits per pixel), where each entry
  130. consists of three byte values representing the relative intensities of
  131. red, green and blue respectively.  The structure of the Color Map block
  132. is:
  133.  
  134.       bits
  135.  7 6 5 4 3 2 1 0  Byte #
  136. +---------------+
  137. | red intensity |  1    Red value for color index 0
  138. +---------------+
  139. |green intensity|  2    Green value for color index 0
  140. +---------------+
  141. | blue intensity|  3    Blue value for color index 0
  142. +---------------+
  143. | red intensity |  4    Red value for color index 1
  144. +---------------+
  145. |green intensity|  5    Green value for color index 1
  146. +---------------+
  147. | blue intensity|  6    Blue value for color index 1
  148. +---------------+
  149. :               :       (Continues for remaining colors)
  150.  
  151.      Each image pixel value received will be displayed according to
  152. its closest match with an available color of the display based on this
  153. color map.  The color components represent a fractional intensity
  154. value from none (0) to full (255).  White would be represented as
  155. (255,255,255), black as (0,0,0) and medium yellow as (180,180,0).  For
  156. display, if the device supports fewer than 8 bits per color component,
  157. the higher order bits of each component are used.  In the creation of a
  158. GIF color map entry with hardware supporting fewer than 8 bits per
  159. component, the component values for the hardware should be converted to
  160. the 8-bit format with the following calculation:
  161.  
  162.      <map_value> = <component_value>*255/(2**<nbits> -1)
  163.  
  164.      This assures accurate translation of colors for all displays.  In
  165. the cases of creating GIF images from hardware without color palette
  166. capability, a fixed palette should be created based on the available
  167. display colors for that hardware.  If no Global Color Map is indicated,
  168. a default color map is generated internally which maps each possible
  169. incoming color index to the same hardware color index modulo <n> where
  170. <n> is the number of available hardware colors.
  171.  
  172. IMAGE DESCRIPTOR
  173.  
  174.      The Image Descriptor defines the actual placement and extents of
  175. the following image within the space defined in the Screen Descriptor.
  176. Also defined are flags to indicate the presence of a local color lookup
  177. map, and to define the pixel display sequence.  Each Image Descriptor
  178. is introduced by an image separator  character.   The role of the Image
  179. Separator is simply to provide a synchronization character to introduce
  180. an Image Descriptor.  This is desirable if a GIF file happens to
  181. contain more than one image.   This character is defined as 0x2C hex or
  182. ',' (comma).  When this character is encountered between images, the
  183. Image Descriptor will follow immediately.
  184.      Any characters encountered between the end of a previous image and
  185. the image separator character are to be ignored.  This allows future
  186. GIF enhancements to be present in newer image formats and yet ignored
  187. safely by older software decoders.
  188.  
  189.       bits
  190.  7 6 5 4 3 2 1 0  Byte #
  191. +---------------+
  192. |0 0 1 0 1 1 0 0|  1 ',' -Image separator character
  193. +---------------+
  194. |               |  2    Start of image in pixels from the
  195. +- Image Left  -+       left side of the screen (LSB first)
  196. |               |  3
  197. +---------------+
  198. |               |  4
  199. +-  Image Top  -+       Start of image in pixels from the
  200. |               |  5    top of the screen (LSB first)
  201. +---------------+
  202. |               |  6
  203. +- Image Width -+       Width of the image in pixels (LSB first)
  204. |               |  7
  205. +---------------+
  206. |               |  8
  207. +-Image Height-+        Height of the image in pixels (LSB first)
  208. |               |  9
  209. +-+-+-+-+-+-----+       M=0 -Use global color map, ignore 'pixel'
  210. |M|I|0|0|0|pixel| 10    M=1 - Local color map follows, use 'pixel'
  211. +-+-+-+-+-+-----+       I=0 - Image formatted in Sequential order
  212.                         I=1 -Image formatted in Interlaced order
  213.                         pixel+1 - # bits per pixel for this image
  214.  
  215.      The specifications for the image position and size must be
  216. confined to the dimensions defined by the Screen Descriptor.  On the
  217. other hand it is not necessary that the image fill the entire screen
  218. defined.
  219.  
  220. LOCAL COLOR MAP
  221.  
  222.      A Local Color Map is optional and defined here for future use. If
  223. the 'M' bit of byte 10 of the Image Descriptor is set, then a color map
  224. follows the Image Descriptor that applies only to the following image.
  225. At the end of the image, the color map will revert to that defined
  226. after the Screen Descriptor.  Note that the 'pixel' field of byte 10 of
  227. the Image Descriptor is used only if a Local Color Map is indicated.
  228. This defines the parameters not only for the image pixel size, but
  229. determines the number of color map entries that follow.  The bits per
  230. pixel value will also revert to the value specified in the Screen
  231. Descriptor when processing of the image is complete.
  232.  
  233. RASTER DATA
  234.  
  235.      The format of the actual image is defined as the series of pixel
  236. color index values that make up the image.  The pixels are stored left
  237. to right sequentially for an image row.  By default each image row is
  238. written sequentially, top to bottom.  In the case that the Interlace or
  239. 'I' bit is set in byte 10 of the Image Descriptor then the row order of
  240. the image display follows a four-pass process in which the image is
  241. filled in by widely spaced rows.  The first pass writes every 8th row,
  242. starting with the top row of the image window.  The second pass writes
  243. every 8th row starting at the fifth row from the top. The third pass
  244. writes every 4th row starting at the third row from the top. The fourth
  245. pass completes the image, writing every other row, starting at the
  246. second row from the top.  A graphic description of this process
  247. follows:
  248.  
  249. Image
  250. Row  Pass 1  Pass 2  Pass 3  Pass 4          Result
  251. ---------------------------------------------------
  252. 0    **1a**                                  **1a**
  253. 1                            **4a**          **4a**
  254. 2                    **3a**                  **3a**
  255. 3                            **4b**          **4b**
  256. 4            **2a**                          **2a**
  257. 5                            **4c**          **4c**
  258. 6                    **3b**                  **3b**
  259. 7                            **4d**          **4d**
  260. 8    **1b**                                  **1b**
  261. 9                            **4e**          **4e**
  262. 10                   **3c**                  **3c**
  263. 11                           **4f**          **4f**
  264. 12           **2b**                          **2b**
  265. . . .
  266.  
  267.      The image pixel values are processed as a series of color indices
  268. which map into the existing color map.  The resulting color value from
  269. the map is what is actually displayed.  This series of pixel indices,
  270. the number of which is equal to image-width*image-height pixels, are
  271. passed to the GIF image data stream one value per pixel, compressed and
  272. packaged according to a version of the LZW compression algorithm as
  273. defined in Appendix C.
  274.  
  275. GIF TERMINATOR
  276.  
  277.      In order to provide a synchronization for the termination of a GIF
  278. image file, a GIF decoder will process the end of GIF mode when the
  279. character 0x3B hex or ';' is found after an image has been processed.
  280. By convention the decoding software will pause and wait for an action
  281. indicating that the user is ready to continue.  This may be a carriage
  282. return entered at the keyboard or a mouse click.  For interactive
  283. applications this user action must be passed on to the host as a
  284. carriage return character so that the host application can continue.
  285. The decoding software will then typically leave graphics mode and
  286. resume any previous process.
  287.  
  288. GIF EXTENSION BLOCKS
  289.  
  290.      To provide for orderly extension of the GIF definition, a
  291. mechanism for defining the packaging of extensions within a GIF data
  292. stream is necessary.  Specific GIF extensions are to be defined and
  293. documented by CompuServe in order to provide a controlled enhancement
  294. path.
  295.      GIF Extension Blocks are packaged in a manner similar to that used
  296. by the raster data though not compressed.  The basic structure is:
  297.  
  298.  7 6 5 4 3 2 1 0  Byte #
  299. +---------------+
  300. |0 0 1 0 0 0 0 1|  1       '!' - GIF Extension Block Introducer
  301. +---------------+
  302. | function code |  2       Extension function code (0 to 255)
  303. +---------------+    ---+
  304. |  byte count   |       |
  305. +---------------+       |
  306. :               :       +-- Repeated as many times as necessary
  307. |func data bytes|       |
  308. :               :       |
  309. +---------------+    ---+
  310. . . .       . . .
  311. +---------------+
  312. |0 0 0 0 0 0 0 0|           zero byte count (terminates block)
  313. +---------------+
  314.  
  315.      A GIF Extension Block may immediately preceed any Image
  316. Descriptor or occur before the GIF Terminator.  All GIF decoders must
  317. be able to recognize the existence of GIF Extension Blocks and read
  318. past them if unable to process the function code.  This ensures that
  319. older decoders will be able to process extended GIF image files in the
  320. future, though without the additional functionality.
  321.  
  322. Appendix A - Glossary
  323.  
  324. Pixel -The smallest picture element of a graphics image.  This usually
  325.    corresponds to a single dot on a graphics screen.  Image resolution
  326.    is typically given in units of pixels.  For example a fairly
  327.    standard graphics screen format is one 320 pixels across and 200
  328.    pixels high.  Each pixel can appear as one of several colors
  329.    depending on the capabilities of the graphics hardware.
  330. Raster -A horizontal row of pixels representing one line of an image.
  331.    A typical method of working with images since most hardware is
  332.    oriented to work most efficiently in this manner.
  333. LSB - Least Significant Byte.  Refers to a convention for two byte
  334.    numeric values in which the less significant byte of the value
  335.    preceeds the more significant byte.  This convention is typical on
  336.    many microcomputers.
  337. Color Map -The list of definitions of each color used in a GIF image.
  338.    These desired colors are converted to available colors through a
  339.    table which is derived by assigning an incoming color index (from
  340.    the image) to an output color index  (of the  hardware).   While the
  341.    color map definitons are specified in a GIF image, the output  pixel
  342.    colors will vary based on the hardware used and its ability to match
  343.    the defined color.
  344. Interlace - The method of displaying a GIF image in which multiple
  345.    passes are made, outputting raster lines spaced apart to provide a
  346.    way of visualizing the general content of an entire image  before
  347.    all of the data has been processed.
  348. B Protocol - A CompuServe-developed error-correcting file transfer
  349.    protocol available in the public domain and implemented in
  350.    CompuServe VIDTEX products.  This error checking mechanism will be
  351.    used in transfers of GIF images for interactive applications.
  352. LZW - A sophisticated data compression algorithm  based  on
  353.    work done by Lempel-Ziv & Welch which has the feature of very
  354.    efficient one-pass encoding and decoding.  This allows the image to
  355.    be decompressed and displayed at the same  time.  The original
  356.    article from which this technique was adapted is:
  357.      Terry A. Welch, "A Technique for High Performance Data
  358.      Compression", IEEE Computer, vol 17 no 6 (June 1984)
  359.    This basic algorithm is also used in the public domain ARC file
  360.    compression utilities.   The CompuServe adaptation of LZW for GIF is
  361.    described in Appendix C
  362.  
  363. Appendix B -Interactive Sequences
  364.  
  365. GIF Sequence Exchanges for an Interactive Environment
  366.  
  367.      The following sequences are defined for use in  mediating
  368. control between a GIF sender and GIF receiver over an interactive
  369. communications line.  These sequences do not apply to applications that
  370. involve downloading of static GIF files and are not considered part of
  371. a GIF file.
  372.  
  373. GIF CAPABILITIES ENQUIRY
  374.  
  375.      The GCE sequence is issued from a host and requests an interactive
  376. GIF decoder to return a response message that defines the graphics
  377. parameters for the decoder.  This involves returning information about
  378. available screen sizes, number of bits/color supported and the amount
  379. of color detail supported.  The escape sequence for the GCE is defined
  380. as:
  381.      ESC [ > 0 g     (g is lower case, spaces inserted for clarity)
  382.                       (0x1B 0x5B 0x3E 0x30 0x67)
  383.  
  384. GIF CAPABILITIES RESPONSE
  385.  
  386.      The GIF Capabilities Response message is returned by an
  387. interactive GIF decoder and defines the decoder's display capabilities
  388. for all graphics modes that are supported by the software.  Note that
  389. this can also include graphics printers as well as a monitor screen.
  390. The general format of this message is:
  391.  
  392.   #version;protocol{;dev, width, height, color-bits, color-res}... <CR>
  393.  
  394. '#'          - GCR identifier character (Number Sign)
  395. version      - GIF format version number; initially '87a'
  396. protocol='0' - No end-to-end protocol supported by decoder
  397.                Transfer as direct 8-bit data stream.
  398. protocol='1' - Can use an error correction protocol to transfer GIF
  399.                data interactively from the host directly to the
  400.                display.
  401. dev = '0'    - Screen parameter set follows
  402. dev = '1'    - Printer parameter set follows
  403. width        - Maximum supported display width in pixels
  404. height       - Maximum supported display height in pixels
  405. color-bits   - Number of bits per pixel  supported.  The number of
  406.                supported colors is therefore 2**color-bits.
  407. color-res    - Number of bits per color component supported in the
  408.                hardware color  palette.   If  color-res is '0' then no
  409.                hardware palette table is available.
  410.  
  411.      Note that all values in the GCR are returned as ASCII decimal
  412. numbers and the message is terminated by a Carriage Return character.
  413.  
  414. Appendix B - Interactive Sequences
  415.  
  416.      The following GCR message describes three standard EGA
  417. configurations with no printer; the GIF data stream can be processed
  418. within an error correcting protocol:
  419.   #87a;1 ;0,320,200,4,0 ;0,640,200,2,2 ;0,640,350,4,2<CR>
  420.  
  421. ENTER GIF GRAPHICS MODE
  422.  
  423.      Two sequences are currently defined to invoke an interactive GIF
  424. decoder into action.  The only difference between them is that
  425. different output media are selected.  These sequences are:
  426.  
  427.   ESC [ > 1 g   Display GIF image on screen
  428.                 (0x1B 0x5B 0x3E 0x31 0x67)
  429.  
  430.   ESC [ > 2 g   Display image directly to an attached graphics printer.
  431.                 The  image may optionally be displayed on the screen as
  432.                 well.
  433.                 (0x1B 0x5B 0x3E 0x32 0x67)
  434.  
  435.   Note that the 'g' character terminating each sequence is in lower
  436. case.
  437.  
  438. INTERACTIVE ENVIRONMENT
  439.  
  440.      The assumed environment for the transmission of GIF image data
  441. from an interactive application is a full 8-bit data stream from host
  442. to micro.  All 25 6 character codes must be transferrable.  The
  443. establishing of an 8-bit data path for communications will normally be
  444. taken care of by the host application programs.  It is however up to
  445. the receiving communications programs supporting GIF to be able to
  446. receive and pass on all 256 8-bit codes to the GIF decoder software.
  447.  
  448. Appendix C -Image Packaging & Compression
  449.  
  450.      The Raster Data stream that represents the actual output image can
  451. be represented as:
  452.  
  453.  7 6 5 4 3 2 1 0
  454. +---------------+
  455. |   code size   |
  456. +---------------+     ---+
  457. |blok byte count|        |
  458. +---------------+        |
  459. :               :        +-- Repeated as many times as necessary
  460. |  data bytes   |        |
  461. :               :        |
  462. +---------------+     ---+
  463. . . .       . . .
  464. +---------------+
  465. |0 0 0 0 0 0 0 0| zero byte count (terminates data stream)
  466. +---------------+
  467.  
  468.      The conversion of the image from a series of pixel values to a
  469. transmitted or stored character stream involves several steps.  In
  470. brief these steps are:
  471.  
  472. 1.  Establish the Code Size -  Define the number of bits needed to
  473.     represent the actual data.
  474.  
  475. 2.  Compress the Data - Compress the series of image pixels to a series
  476.     of compression codes.
  477.  
  478. 3.  Build a Series of Bytes -Take the set  of compression codes and
  479.     convert to a string of 8-bit bytes.
  480.  
  481. 4.  Package the Bytes -Package sets of bytes into blocks preceeded by
  482.     character counts and output.ESTABLISH CODE SIZE The first byte of
  483.     the GIF Raster Data stream is a value indicating the minimum number
  484.     of bits required to represent the set of actual pixel values.
  485.     Normally this will be the same as the number of color bits.
  486.     Because of some algorithmic constraints however, black & white
  487.     images which have one color bit must be indicated as having a code
  488.     size of 2.   This code size value also implies that the compression
  489.     codes must start out one bit longer.
  490.  
  491. COMPRESSION
  492.  
  493.      The LZW algorithm converts a series of data values into a series
  494. of codes which may be raw values or a code designating a series of
  495. values.  Using text characters as an analogy, the output code consists
  496. of a character or a code representing a string of characters.  The LZW
  497. algorithm used in GIF matches algorithmically with the standard LZW
  498. algorithm with the following differences:
  499.  
  500. 1.  A special Clear code is defined which resets all
  501.     compression/decompression parameters and tables to a start-up
  502.     state.  The value of this code is 2**<code size>.  For example if
  503.     the code size indicated was 4 (image was 4 bits/pixel) the Clear
  504.     code value would be 16 (10000 binary).  The Clear code can appear
  505.     at any point in the image data stream and therefore requires the
  506.     LVW algorithm to process succeeding codes as if  a  new  data
  507.     stream was starting.  Encoders should output a Clear code as the
  508.     first code of each image data stream.
  509.  
  510. 2.  An End of Information code is defined that explicitly indicates the
  511.     end of the image data stream.  LZW processing terminates when this
  512.     code is encountered.  It must be the last code output by the
  513.     encoder for an image.  The value of this code is <Clear code>+1.
  514.  
  515. 3.  The first available compression code value is <Clear code>+2.
  516.  
  517. 4.  The output codes are of variable length, starting at <code size>+1
  518.     bits per code, up to 12 bits per code.  This defines a maximum code
  519.     value of 4095 (hex FFF).  Whenever the LZW code value would exceed
  520.     the current  code length, the code length is increased by one.  The
  521.     packing/unpacking of these code s must then be altered to reflect
  522.     the new code length.
  523.  
  524. BUILD 8-BIT BYTES
  525.  
  526.      Because the LZW compression used for GIF creates a series of
  527. variable length codes, of between 3 and 12 bits each, these codes must
  528. be reformed into a series of 8-bit bytes that will be the characters
  529. actually stored or transmitted.  This provides additional compression
  530. of the image.  The codes are formed into a stream of bits as if they
  531. were packed right to left and then picked off 8 bits at a time to be
  532. output.   Assuming a character array of 8 bits per character and using
  533. 5 bit codes to be packed, an example layout would be similar to:
  534.  
  535.  byte n       byte 5   byte 4   byte 3   byte 2   byte 1
  536. +-.....-----+--------+--------+--------+--------+--------+
  537. | and so on |hhhhhggg|ggfffffe|eeeedddd|dcccccbb|bbbaaaaa|
  538. +-.....-----+--------+--------+--------+--------+--------+
  539.  
  540.      Note that the physical packing arrangement will change as the
  541. number of bits per compression code change but the concept remains the
  542. same.
  543.  
  544. PACKAGE THE BYTES
  545.  
  546.      Once the bytes have been created, they are grouped into blocks for
  547. output by preceeding each block of 0 to 255 bytes with a character
  548. count byte.  A block with a zero byte count terminates the Raster Data
  549. stream for a given image.  These blocks are what are actually output
  550. for the GIF image.  This block format has the side effect of allowing a
  551. decoding   program the ability to read past the actual image data if
  552. necessary by reading block counts and then skipping over the data.
  553.  
  554. Appendix D -Multiple Image Processing
  555.  
  556.      Since a GIF data stream can contain multiple images, it is
  557. necessary to describe processing and display of such a file.  Because
  558. the image descriptor allows  for  placement of the image within the
  559. logical screen, it is possible to define a sequence of images that may
  560. each be a partial screen, but in total fill the entire screen.
  561.  
  562. The guidelines for handling the multiple image situation are:
  563.  
  564. 1.  There is no pause between images.  Each is processed immediately as
  565.     seen by the decoder.
  566.  
  567. 2.  Each image explicitly overwrites any image already on the screen
  568.     inside of its window.  The only screen clears are at the beginning
  569.     and end of the GIF image process.   See discussion on the GIF
  570.     terminator.